Today, when a software engineer develops an application, the software engineer will typically use documentation about how a particular service works. For example, a web service may provide documentation about how to access features of the web service in the form of an Application Programming Interface (API). The software engineer will take the documentation and generate an application that accesses various services provided by the API. However, in many instances, the documentation does not always match the API. This can be due to errors that are introduced as the documentation is written. Other problems can occur when specific information about how the API work is left undocumented or there is limited documentation about specific features of the API. For instance, a function call may return an undocumented error code or an error code with limited explanation. This can lead to frustration by software engineers and service errors due to the inconsistency and incompleteness in the documentation about the actual APIs. And this is in addition to the increased time and effort to develop applications that use the APIs and are compatible to the required service flow.
There are various ways that providers of services have tried to address this issue. For example, extensive testing of API and documentation can be performed. However, this leads to increased time and expense in producing the API documentation. Companies have addressed issues like these by providing customer support. This leads to increased technical support costs. What is needed is a way to easily create applications without having to write programs based on separate API documentation; this will allow applications to be easily created in less time, at less cost, and with less error.